Users of computing devices (e.g., laptops, cellular phones, and personal digital assistants) often need to communicate in real time. A common form of real-time communications is provided by instant messaging services. An instant messaging service allows participants at endpoints to send messages and have them received within a second or two by the other participants in a conversation. The receiving participants can then send responsive messages to the other participants in a similar manner. To be effective, a real-time conversation relies on the participants' becoming aware of, reviewing, and responding to received messages very quickly. This quick response is in contrast to conventional electronic mail systems in which the recipients of electronic mail messages respond to messages at their convenience.
To support real-time communications, communications applications typically need to establish and manage connections (also referred to as sessions or dialogs) between computing devices. A session is a set of interactions between computing devices that occurs over a period of time. As an example, real-time communications applications such as MESSENGER or VoIP establish sessions between communicating devices on behalf of users. These applications may use various mechanisms to establish sessions, such as a “Session Initiation Protocol” (“SIP”). SIP is an application-level control protocol that computing devices can use to discover one another and to establish, modify, and terminate sessions between computing devices. SIP is a proposed Internet standard. The SIP specification “RFC 3261” is available at <www.ietf.org/rfc/rfc3261. txt>.
Applications may employ SIP with a lower-level protocol to send or receive messages. SIP may use lower-level connections to transport a dialog's messages, such as Transmission Control Protocol/Internet Protocol (“TCP/IP”), which are commonly employed transport- and network-layer protocols. Transmission Control Protocol (“TCP”) is a connection-oriented, reliable-delivery transport-layer protocol. TCP is typically described as a transport layer that provides an interface between an application layer (e.g., an application using SIP) and a network layer. The application layer generally communicates with the TCP layer by sending or receiving a stream of data (e.g., a number of bytes of data). TCP organizes this data stream into segments that can be carried by the protocol employed at the network layer, e.g., the Internet Protocol (“IP”). These segments of data are commonly referred to as “packets,” “frames,” or “messages.” Each message generally comprises a header and payload. The header comprises data necessary for routing and interpreting the message. The payload comprises the actual data that is being sent or received. The application, transport, and network layers, together with other layers, are jointly referred to as a data communications stack.
When an initiating participant wants to start a real-time conversation, that participant needs to know whether the intended participants are available to respond in real time to a message. If not, then communication via conventional electronic mail, voice mail, or some other mechanism may be more appropriate. For example, if the computing devices of the intended participants are currently powered off, then a real-time conversation may not be possible. Moreover, if their computing devices are currently powered on, but the intended participants are away from their computers, a real-time conversation is also not possible. The initiating participant would like to know the availability of the intended participants so that an appropriate decision on the form of communication can be made.
The availability status of an entity such as a computing device (i.e., endpoint) or a user associated with that computing device is referred to as “presence information.” Presence information identifies the current “presence state” of the user. Users make their presence information available so that other users can decide how best to communicate with them. For example, the presence information may indicate whether a user is logged on (“online”) with an instant messaging server or logged off (“offline”). Presence information may also provide more detailed information about the availability of the user. For example, even though a user is online, that user may be away from their computing device in a meeting. In such a case, the presence state may indicate “online” and “in a meeting.”
In an instant messaging context, a publishing user (“publisher”) may provide their presence information to a presence server that then provides the presence information to subscribing users (“subscribers”). Thus, a presence server may use a subscriber/publisher model to provide the presence information for the users of the presence service. Whenever the presence information of a user changes, the presence server is notified of the change by that user's computing device, and in turn the presence server notifies the subscribing users of the change. A subscribing user can then decide whether to initiate an instant messaging conversation based on the presence information of the intended participants. For example, if the presence information indicates that a publishing user is currently in a conference telephone call, then the subscribing user may decide to send an instant message, rather than place a telephone call, to the publishing user. If the subscribing user, however, needs to call and speak with the publishing user, the subscribing user needs to monitor the presence information of the publishing user to know when the call can be placed. When the subscribing user notices that the publishing user's presence information indicates that the telephone conference has been concluded, the subscribing user can then place the telephone call. A specification relating to presence information in instant messaging systems, “RFC 2778, ” is available at <www.ietf.org/rfc/rfc2778. txt>.
It is not uncommon for participants to be connected over a connection that is intermittently available (i.e., unreliable). For example, a laptop may be connected to a wireless network that fades in and out, or a user may be connected through a home server that is overloaded or is frequently reset. Networking equipment between two connected users may frequently fail and recover. In environments where network connections are unreliable, messages sent by real-time messaging clients often fail to get delivered to the recipient. When a message fails to get delivered, the sending client may display a delivery error message to the user. In many cases, the connection may quickly return, such as when the user is near the edge of reception of a wireless network. If the user's connection frequently disconnects and reconnects, the user may see multiple error messages, contributing to a poor experience for the user. When a participant has multiple endpoints connected to a real-time messaging service (i.e., multiple points of presence or MPOP), such as a laptop, a desktop, and a cell phone, the problem may be even worse. In MPOP scenarios, invitations to join a conversation are often received by the real-time messaging service and forwarded to each of a participant's connected endpoints. Often the most active endpoint will automatically accept the invitation. For example, if a user is having a conversation on a wirelessly connected laptop, and the wireless connection is disconnected, then the user's desktop may accept an invitation from a sending participant to reinitiate the conversation. The sending participant may never notice that he is communicating with a different endpoint, and the receiving user may never see the messages if she is not near her desktop.